…erence

#259 checkpoint 1, implementation. The census (5030314) opened at 12 Rust-only
accepts; this closes them and makes the crate's long-standing claim to "mirror
the acceptance of Python load exactly" true for the first time.

Matrix over the 77-control ledger, all three failure rows required zero:

  python accept / rust accept : 10
  python reject / rust reject : 67   (same category)
  python reject / rust ACCEPT :  0   (was 12)
  python accept / rust REJECT :  0
  category mismatch           :  0   (was 5)

Four mechanisms, not twelve special cases:

* SIX fields were not declared in the Rust model at all (`source_provenance`,
  `ignore_reason`, `sig`, `column`, `protocols`, `protocol_functions`), so they
  fell into serde(flatten) `extra` and escaped checking. serde is admirably
  strict about fields it has been told about. Each is declared with ITS OWN
  semantics — `resource` rejects null, the nullable-optionals accept it — not
  one blanket policy, since sharing a bug is not sharing a contract.
* the 1-based column rule (#317): 0, negative, bool and string.
* the closed `resource` vocabulary (IR4).
* protocol-name identity.

Errors are now typed. `OwnIrErrorKind` = Json | Version | Shape | Vocabulary |
Identity | Location, one variant per mechanism a loader can reject on. The
ledger fails if a declared category has no control exercising it, so the
taxonomy cannot outgrow its evidence — which is why there is no `Reference`
variant: the sweep found no load-time referential constraint.

Category is compared, message text never is. The reference funnels everything
into one OwnIRError whose strings are a presentation aid. Equally, the expected
category is DECLARED by the ledger and confirmed by the oracle only as
accept/reject — deriving it from Python's message would abandon message parity
at the front door and rebuild it as regex parity at the back.

The mechanism must not pick the category. A serde enum would reject
`lifetime: "eternal"` perfectly well and call it Shape, when the contract is a
closed vocabulary; a typed NonZeroU32 column would call a 0 Shape when the
contract is a coordinate. So vocabulary/identity/location run in a gate over the
RAW document before deserialization — which also gets the BR-D1 order right,
where the version gate must precede shapes.

Both doors keep their unknown-resource check. The strict door now rejects at
load (cp1); the lowerer keeps its own (#294 OD-2) because the tolerant path
bypasses `load()` entirely. This became load-bearing immediately: the bridge's
`tolerant_unknown_kind` fixture was routing through `from_json`, so a strict
door that enforces IR4 made the tolerant-door test unreachable. It now
deserializes directly, as its real callers do.

Seven mutations, one per mechanism plus one that only misclassifies a category
while still rejecting — all caught. That last one is the guard against a
decorative taxonomy.

P-022's cp1 row corrected: it conflated the two doors, reading as though OD-2
satisfied cp1.

Refs #259, #250.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

…the port

Independent review found seven divergences the 77-control ledger cannot see, so
the 0/0/0 matrix was true only over the controls I wrote. Each verified against
the reference before recording:

  absent service.lifetime          python reject / rust ACCEPT
  params[].column: 0 (+ flow body) python reject / rust ACCEPT
  protocols: [7], malformed records python reject / rust ACCEPT
  column > i64::MAX                python ACCEPT / rust reject   <- over-strict
  components shape vs later service semantics   Shape vs Vocabulary
  lifetime-before-name order       reference checks lifetime first
  protocol-duplicate-name control  rejects on record shape, not the duplicate

Two are structural rather than missing branches.

Ordering: BR-D1 interleaves shape-then-semantics per section. This port runs
every semantic check before deserialization, which got the version gate right
and everything after it wrong — `{components:{}, services:[{lifetime:"bad"}]}`
answers Vocabulary where the reference answers Shape. Fixing it means
interleaving per section, not adding another check.

Range: Python integers are unbounded and `_check_column` accepts any positive
one. `as_i64()` returns None above i64::MAX, so a document the reference accepts
is rejected. The over-strictness row was never actually zero.

The honest lesson is about the ledger, not the port. I wrote both, so a gap in
my reading of the contract produced a matching gap in each, and the matrix read
green — `_svc` always set `lifetime`, so no control could ever omit it. A
same-author oracle measures the author's understanding, not the contract. The
reviewers found these precisely because they were not the author.

The claim is corrected before the fixes land rather than after, so the PR does
not sit on a false "complete" while the work is done.

Refs #259, #250.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

… port

The first census reached 0/0/0 over 77 controls and was recorded as
complete. Review then found seven divergences it could not express.

The cause was structural, not careless: the same author wrote the oracle
and the port, so one gap in reading BR-D1 produced a matching gap in
each and the matrix agreed with itself. The sharpest instance is
`_svc()`, which always supplied `lifetime` — so no control could omit
it, and the reference rejects an absent lifetime while the port accepts
it. Mutation testing proved the implementation against the ledger.
Nothing proved the ledger against the contract.

So this round is derived by reading `load()` and the shared obligation
parser line by line, before looking at what the port does with them.
191 controls, up from 77.

New families:
  - required fields ABSENT (the `_svc()` blind spot), plus `_proto()`
    and `_pfn()` helpers that build deliberately incomplete records
  - ordering WITHIN a section: lifetime-before-name, sig-before-body,
    body-columns-before-params, param name/line/column/effect
  - ordering ACROSS sections: BR-D1 interleaves shape and semantics per
    section, so a components SHAPE failure outranks a services
    VOCABULARY failure. Six controls chain every section boundary
  - flow columns, recursive through then/else/body to three levels
  - params[].column, a separate reference call site the port lacked
  - the protocol acceptance grammar delegated to obligations.py:
    parse_protocol / parse_matcher / parse_events / parse_method,
    with valid twins first — the old duplicate-name control used
    records with no opens/closes, so it never reached the duplicate
    branch it claimed to test
  - explicit null on every section and scalar (present null is not
    absent), and the three places where null IS accepted
  - integer boundaries pinned at i64::MAX, where both sides agree

Measured RED at this commit, all three rows in one reading:

  agreed accept                   29
  agreed reject                   95
  python reject / RUST ACCEPT     58
  python accept / rust reject      0
  category mismatch                9

The nine mismatches are the architecture, not nine oversights: absent
required fields surface as serde `Shape` instead of the contract's
vocabulary/identity, and "all semantics, then all shapes" inverts
precedence both within and across sections.

The replay now reports all three failure rows in one assertion instead
of three sequential ones. Sequential asserts show only the first
non-empty row, which is how a 58-and-9 census would have read as a
permissiveness problem alone.

Integer width is measured and deliberately NOT covered: Python ints are
unbounded and every line/column field accepts values past 64 bits, so
Rust is over-strict across seven field families. Widening Rust to
arbitrary precision to honour a nine-quintillion source coordinate is
the wrong repair; the boundary is pinned where both agree and the range
above it is a separate Python-first defensive limit.

No production code changed in this commit.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Closes the 58 permissive documents and 9 category mismatches the
re-census opened. The fix is architectural: no arrangement of the
previous design could have passed.

The previous door ran `version gate -> all semantic gates -> serde for
all shapes`. That is a third check order, matching neither
implementation. BR-D1 validates each section COMPLETELY before the next
begins, interleaving shape and semantics inside it — so a `components`
shape failure outranks a `services` vocabulary failure, and within a
service `lifetime` outranks `name`. Hoisting semantics in front of serde
gets section-local controls right and every ordering control wrong.

So the strict door is now a sequential validator over the raw document:

  own-ir/src/strict.rs    primitives + one function per section, applied
                          in the reference's order
  own-ir/src/protocol.rs  the obligation ACCEPTANCE grammar

Not 47 transcribed `if`s — eight primitives, each encoding one of
Python's access idioms, and section validators that apply them:

  objects / list      d.get(k, []) as a container
  name_slot           isinstance(v, str) and v — a value facts join on
  optional_string     `is not None and not isinstance` — null tolerated
  defaulted_string    isinstance(d.get(k, "?"), str) — null rejected
  defaulted_int       int and not bool
  string_array        list of str
  column              the 1-based contract (#317), recursive over flow
  sites               the {type, file, line} record

The two string primitives are the place a single "policy for optional
fields" would be silently wrong: `resource` rejects an explicit null and
`source_provenance` accepts it, because the reference writes one as a
defaulted isinstance and the other as `is not None and ...`.

serde is now the CONSTRUCTOR, not the arbiter. Once the validator
accepts, a serde failure means a rule lives in the model rather than the
validator — its category and its ordering would both be accidental. That
is marked with a sentinel and asserted against by
`no_control_escapes_into_serde`, which is not decoration: five of the 27
mutations below are caught by it ALONE, because the model still enforced
the rule while the validator no longer did.

`OwnIr::validate` is now `to_value` + the same validator. It costs a
round-trip and buys single-copy-of-the-law — the property whose absence
already produced a false "mutation survived" in this PR, when a planted
mutation hit one copy of a duplicated check and the other caught it.

Protocol scope, exactly as agreed: `parse_protocol`, `parse_matcher`,
`parse_events`, `parse_method` — what the door ACCEPTS. Not the
lattice, the walker, matching, or verdicts. `protocols` and
`protocol_functions` stay raw `Value`s with pure validation beside them,
because nothing consumes a typed representation yet. Two of the grammar's
rules ("can never fire", "barrier equals opens") are well-formedness
rather than shape; they are recorded as `shape` with the taxonomy strain
written down rather than a seventh category invented unilaterally.

Final matrix over 191 controls:

  agreed accept                   29
  agreed reject                  162
  python reject / rust accept      0
  python accept / rust reject      0
  category mismatch                0

27 mutations, all caught — one per mechanism, plus three that only
change a category while still rejecting, plus two that only change
ORDER. The order mutations matter most: they are the ones the previous
architecture could not have failed.

Also fixed: `is_none_or` needs Rust 1.82 and the workspace MSRV is 1.74;
three `private_intra_doc_links` of the same class #324 hit; and the
replay now reports all three failure rows in one assertion, since
sequential asserts showed only the first and would have made this a
two-round discovery.

Still open and deliberately not closed here: Python integers are
unbounded, so every line/column field accepts values past 64 bits and
Rust is over-strict above i64::MAX across seven field families. The
ledger pins the boundary where both agree. The range above it is a
Python-first defensive limit, not a reason to thread arbitrary-precision
integers through own-ir and the bridge.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

The proposals index named lowering and MOS but not validation, so the
third surface disagreed with the other two the moment cp1 landed.

P-022 and #250 were updated in the same change (#250 via the API, no git
commit): the status-drift rule says the surfaces move together.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

…walk

Review finding on e5f52e8: `OwnIr::validate()` can be handed an
arbitrarily deep in-memory value, and nothing stops the recursion. Real,
and introduced by this PR — before e5f52e8 `validate()` did not recurse
at all.

The proposed fix was a depth counter threaded through `events`. Measured
against the tree, that would have been dead code. Binary search on the
same tree:

  to_value()  survives to ~831, aborts by ~846
  validate()  survives to ~831, aborts by ~846

Identical, because `validate` serializes first. The stack dies inside
`serde_json::to_value` before the validator's own recursion is ever
reached, so a counter in `events`/`flow_columns` could never be the check
that fires. The bound has to run BEFORE serialization.

So the guard is in `to_value`, which already returns `Result`:

  - `strict::check_depth` measures depth with an EXPLICIT STACK. A
    recursive depth check would be the failure it is meant to prevent,
    and would abort rather than return — a stack overflow is not
    catchable.
  - `OwnIr::check_raw_depth` walks the raw values the model carries
    (`extra` maps, both protocol sections, `Subscription::column`) with
    plain loops; typed nesting is fixed-depth, so no recursion there.
  - The limit is 128, serde_json's own parse limit. A document that
    could be PARSED never exceeds it, so this rejects nothing
    `from_json` accepts.

`from_json` was never exposed: serde_json caps nesting at 128 and
refuses around 120 event levels.

HONESTY NOTE, measured not assumed: this covers depths 129..~800. Above
~804 merely DROPPING the value aborts, because `serde_json::Value` has a
recursive `Drop` — nothing this crate does can prevent that, and a test
asserting otherwise aborts before it can report. The first version of
the regression test used depth 900 and died in `Drop`, which is how the
band got measured. The guard stops the serializer, not the type.

Also corrected: two doc comments claimed recursion was "bounded by
serde_json's 128-level parse limit". True for `from_json`, false for a
value built in memory — which is precisely the gap the finding names.

Four mutations, all caught — but only after fixing the second test.
`the_depth_guard_never_fires_on_a_document_from_json_accepts` originally
ran over the ledger alone, and every control is a few levels deep, so
tightening the guard to 16 SURVIVED. It now builds the deepest document
`from_json` still accepts (50 nested events, ~105 JSON levels) and pins
the guard above it. Same lesson as the census: a test that cannot
distinguish the mutation is not evidence, whatever it asserts.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Recounted from the fixture rather than from memory: of the 58 permissive
documents the second census opened, 47 are protocol-grammar cases
(`protocols`, `protocol_functions`, and their two ordering families) and
11 are the flow/param column families.

A wrong number in a module doc that exists to justify a scope decision
is worse than no number.

Refs #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Veto on filing two protocol rules under `shape`, and the reasoning
behind the veto is the part worth keeping.

`protocol can never fire` (no barriers with `exit_barriers: false`) and
`barrier == opens` were reported as `Shape` while the code comment
directly above them said "both are well-formedness, not shape". Every
value in such a record has the right type and a legal vocabulary; what
is broken is that the record cannot MEAN anything.

The justification given was that the taxonomy was already frozen at six.
That is backwards. The taxonomy was frozen by the FIRST census; this
mechanism was found by the SECOND — the same census that just proved a
category set settled early is a claim about the settling, not about the
contract. Filing a newly discovered mechanism under the nearest existing
name is the exact substitution this enum was built to stop, and it was
the substitution being made.

So: `OwnIrErrorKind::WellFormedness`, wire name `well_formedness`. Both
rules move to it. The enum's doc now states the set is closed by
measurement in BOTH directions — it cannot outgrow its evidence (no
`Reference` variant, nothing reaches it) and it is not frozen against
new evidence.

Ledger: 191 -> 193 controls. The two new ones are the acceptance twins
the category needs — `exit_barriers: false` WITH a barrier, and a
barrier that differs from `opens` — so the rejections are about meaning
rather than about the fields being present at all.

Four mutations, all caught, including the two that matter most here:
each rule reported as `Shape` while still rejecting. Category-only
mutations are the only thing that can tell a real taxonomy from a
decorative one.

Also, per review: 128 is now the ONLY normative depth number.

The measured abort points (~831/~846 for serialization, ~804/~851 for
`Drop`) are properties of one stack size, build profile and platform.
They are good forensics and they were creeping into doc comments as if
they were specification; they are out of the normative wording and the
PR keeps them as evidence.

And the guard's promise is stated precisely instead of absolutely. It
was "nothing this crate does can prevent that". Correctly: `to_value()`
and `validate()` refuse a too-deep value and RETURN rather than aborting
inside the serializer. They do not promise that any `Value` a caller
built is safe to hold — `serde_json::Value` has a recursive `Drop`.
Guaranteeing that would mean not representing facts as
`serde_json::Value`, a representation change and outside cp1.

Status, per the same review: cp1 is NOT complete and P-022 + the index
now say so. 0/0/0 currently means "over a set from which two known
Python-accept/Rust-reject families were removed" — coordinates beyond
Rust's integer range, and deep nesting. That is not the parity #259
asks for. Both close Python-first, before this checkpoint may be called
complete. #250 is corrected in the same logical change, via the API.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Review raised one of these as a nitpick against `af6e782`. Checking it
against the current tree found four more, all mine, all introduced by
not re-reading doc comments after the architecture changed under them.

  * the crate doc still said the ledger was **191** controls; the
    seventh category took it to 193. Same number stale in the depth test.
  * `Subscription::column` said the check "lives in `OwnIr::validate`".
    It lived in `gate_components` when that was written, and both are
    gone: it is `strict::column`, reached from `from_json` and
    `validate` alike.
  * `OwnIr::protocols` was the bad one. It still read "Record-level
    validity beyond that is NOT yet mirrored" — the exact claim this PR
    retracted. The reference CALLS the obligation parser inside `load()`
    and wraps its errors, so it is part of the door, and the second
    census measured that supposed boundary as 47 of its 58 permissive
    documents. The comment was describing the bug as if it were the
    design.
  * `OwnIr::protocol_functions` repeated it by reference.

Worth naming: the misleading one was not the one review found. It was
found by grepping for every stale symbol at once — `gate_*`, `191`,
`OwnIr::validate` — rather than fixing the line that was pointed at.
A doc comment that survives the code it documents is the same failure
class as a test that survives the behaviour it asserts; neither gets
re-read just because something near it changed.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Review nitpick, and it is the same failure as the last three: the depth
test asserted something weaker than it claimed.

It built a FIXED 50-wrapper document and said it was "the deepest
document `from_json` still accepts". It was not — the parser reaches ~61
wrappers. Any guard between the two passes the test while rejecting
documents the door accepts, which is precisely the new-rejection-rule
the test exists to forbid.

Measured, by restoring the old shape and mutating against both:

  guard 55   fixed-50: caught     discovered: caught
  guard 105  fixed-50: PASSES     discovered: caught

So the boundary is now discovered rather than sampled: walk depth upward
until `from_json` refuses, keep the deepest document it accepted, and
require that one to survive `to_value`. That states the contract exactly
— "the guard never fires on anything the parser accepts" — instead of
picking a depth that happens to sit under it.

Three guard mutations caught (55, 105, and 16 as a regression).

Also fixed, from the same review: `#260/#269` opened line 76 of P-022 and
markdownlint read it as an ATX heading (MD018). Same class as the one
caught in #322; reflowed.

DECLINED, with the measurement: the review also asked to reconcile
P-022's "31/162, 31 mutations" against the PR body's "29/162, 27". The
direction is inverted — P-022 is right and the BODY is stale. Measured:

  ownir validation ledger OK: 193 controls (31 accept / 162 reject)

31 accepts and 162 rejects is the post-`WellFormedness` ledger, and 31
mutations is 27 plus the four that category needed. The PR body still
carried the pre-seventh-category numbers; it is corrected there rather
than by editing the correct figures to match the wrong ones.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

Measured RED. No production code in this commit — the point is the number
before the fix, and a fix landing beside its own evidence cannot be checked
against it.

#326 closed both families Python-first, so the reason for excluding them is
gone. The previous census reported 0/0/0 over a set from which the two places
the implementations were known to disagree had been removed. That is a true
statement about a chosen subset, not the parity #259 asks for, and the honest
way to find out what it was hiding is to put the cases back.

193 controls -> 216. The three mechanisms it opens are distinct:

  matrix: agreed_accept 35, agreed_reject 166,
          rust_only_accept 7, rust_only_reject 0, kind_mismatch 8
  plus 8 controls escaping into serde (VALIDATOR_HOLE)

Eight `line` paths escape into serde. `is_integer()` answers "is this an
integer" and `i64::MAX + 1` still is one to the parser, so the raw layer waves
it through and the typed model refuses it afterwards. The rule was living in
the model rather than in the door, which makes both its category and its
ordering accidental — exactly what the sentinel exists to name. It fires on
services line, ctor_line, both site arrays, effect, binding and param.

Seven documents the reference refuses are ACCEPTED by the port: all six
nesting-past-limit controls, since the port has no depth rule at all, and
`event-line-above-i64`, which does not even reach the sentinel — protocol
events are stored raw, so serde never gets a chance to refuse the value and
the document is analysed with a coordinate no consumer can hold.

Eight controls reject on both sides and disagree about why, and this is the
finding worth the most. `column` was reading its category off the reference's
DIAGNOSTIC rather than off the mechanism: `_check_column` raises one message
for a bool, a string, a float, an out-of-range integer and a zero alike, and
the ledger inherited that single message as a single category. So a bool
column was `location` — a "1-based contract violation" for a value that has no
integer form for the 1-based rule to be about.

The conflation was visible in the file and read as intent. `column-float` was
`location` and `line-float` was `shape`, adjacent, with a comment explaining
that a float column and a float line "are the same, where it is a shape
failure instead". One violation, two categories, documented as a decision.

The taxonomy is therefore split along the axis it was always missing:

  shape     the value has no representable primitive or container form the
            contract requires
  location  a REPRESENTABLE coordinate violating its coordinate-domain rule,
            currently the 1-based column

`representable` is load-bearing and belongs to OwnIR, not to serde:
`i64::MIN - 1` is `shape` because §4.2 declared signed-64 the representable
integer form, not because a parser turned it into a float. Measured, the
parser reaches these values by two routes — `i64::MAX+1 ..= u64::MAX`
materialises as u64, anything outside `i64::MIN ..= u64::MAX` drops to f64,
and there is no negative u64 band, so the two ends are not mirror images.
Recovering the lost token would need `arbitrary_precision`. One category over
both routes removes the need to, and refuses to let the parser's
materialisation choose the semantics.

Six existing controls move `location` -> `shape`. Nothing else about them
changes: Python's accept/reject is untouched, its message text is untouched,
and the reference is not edited in this commit or the next. Only our
cross-language classification of the cause moves.

Checked before doing it, because the risk was real: all four cross-category
`order-*` controls use `column: 0`, so they stay genuine `location` controls
and the BR-D1 ordering evidence survives the split intact. A taxonomy fix that
had quietly turned `location`-before-`vocabulary` into `shape`-before-`shape`
would have bought a cleaner enum with a vacuous ordering proof.

Three of the new coordinate controls are green on arrival — `line-below-i64`,
`line-above-u64` and `line-float` already reject as `shape`, because they take
the f64 route into the same branch as a plain float. They are kept as
regression guards for the half of the range that was accidentally right.

Precedent for changing the taxonomy on new evidence is the taxonomy's own:
`WellFormedness` was added when the nearest existing category was found
inadequate. A category set that survives one census is a claim about that
census.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

GREEN for the RED measured in the previous commit. 216 controls, matrix
35 / 181 / 0 / 0 / 0, no control escaping into serde.

Three mechanisms, one idea: the strict door decides what a value IS before
anything decides what it MEANS.

`is_integer` becomes `is_representable_int` and narrows from
`is_i64() || is_u64()` to `is_i64()`. That is not an extra check bolted beside
the type check — it IS the type check, finally stated at the width OwnIR has.
The old predicate answered "is this an integer at all", which `i64::MAX + 1`
satisfies, so the raw layer waved it through and the typed model refused it
afterwards. Because the predicate is shared, all eight validated `line` paths
close at once, and `sites` and `column` close with them.

`column()` splits into four outcomes in order: absent or null accepts,
unrepresentable is `Shape`, representable-and-below-1 is `Location`,
representable-and-at-least-1 accepts. It is the only field carrying both axes,
which is why it is where they were conflated — one predicate reported a bool,
a string, a float and an out-of-range integer as a "1-based contract
violation", for values with no coordinate in them for the rule to be about.

Nesting gets the contract's own domain limit, mirrored from the reference
rather than chosen here. Two recursions, and deliberately not symmetrical: the
flow walker checks depth AFTER the early return, the event walker BEFORE the
list check. That is not sloppiness, it is the reference — a missing event arm
is read as `e.get("then", [])` and still descends a level, while the flow
walker probes for a key that may not be there and must not count what it did
not find. Mutating either into the other's shape is caught.

`OwnIrErrorKind::Shape` and `::Location` are re-documented around the word
representable, because that word is what makes the split a contract rule
instead of an implementation detail: `i64::MIN - 1` is `Shape` because §4.2
declared signed-64 the representable form, not because serde_json flattened it
to a float on the way in.

The depth witness had to move, and finding out why is the most useful thing in
this commit. `the_depth_guard_never_fires_on_a_document_from_json_accepts`
nested a protocol event tree and walked until `from_json` refused. Correct
while nothing bounded that tree — and the nesting rule above bounds it. So the
walk started stopping at the door instead of at the parser, and the assertion
quietly degraded from "the guard is looser than the parse ceiling" to "the
guard is looser than 32". Measured, immediately after the rule landed:

  witness = event tree           deepest 32, terminating error Shape
  witness = unknown top section  deepest 62, terminating error Json

Two halves to the fix. The witness moves to an unknown top-level section,
which the door tolerates by design and the ledger pins. And the walk now
ASSERTS that what stopped it was `OwnIrErrorKind::Json`. Only the second half
generalises: picking an unbounded witness is a fact about today's rules, and
the last witness stopped being one without saying so. Now any future rule that
shadows the parse boundary fails here, naming its own kind.

The schema binding map is closed over `$defs` the same way. It checked the
defs it already named, so a coordinate-bearing def added later would be in
neither BOUND nor UNBOUND and checked by nothing, while the test went on
passing — an assertion proving the completeness of a list, using the list.
Discovery now walks `$defs` and the two sets must be equal.

Mutation campaign: 17 mutations, 17 caught.

  1  is_representable_int widened back to u64
  2  column's representability branch removed
  3  representability answers Location instead of Shape
  4  flow depth off-by-one
  5  flow depth never fires
  6  flow depth not threaded through then/else/body
  7  flow depth check moved BEFORE the early return
  8  event depth off-by-one
  9  event depth not threaded into `while`
  10 event depth not threaded into `else`
  11 event depth check moved AFTER the list check
  12 event line loses its range check
  13 MAX_VALUE_DEPTH 128 -> 40
  14 depth witness moved back to the event tree
  15 a new coordinate-bearing $def, classified by nobody
  16 a classified $def loses its coordinate
  17 discovery walk narrowed to top-level properties

13 and 14 are the pair worth reading together: 13 was invisible under the old
witness and 14 restores the old witness, so each is the other's guard. 7 and
11 are the same pair for the two recursions.

The campaign was also run once with `git checkout` as its restore step, which
reverted the uncommitted fix along with the mutation and reported anchors
missing and one compile error as a catch. Re-run against file copies. A
mutation harness that cannot tell "the guard caught it" from "the build broke"
measures nothing, and this is the third distinct way that has happened on this
track.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM

The status surfaces move together, so P-022 and the proposals index are the
same change; #250 and the PR body follow separately because they live on
GitHub.

cp1 goes from "acceptance surface closed except two named families" to
complete. The row is rewritten rather than edited, because the interesting
content changed: there were three censuses, not two, and the third is the one
that produced a result worth quoting.

What the third census found is recorded, not just its number. Admitting the
two excluded families opened 7 permissive documents and 8 category mismatches,
and the defect underneath the mismatches was that the ledger had been reading
its category off the reference's DIAGNOSTIC rather than off the mechanism —
`_check_column` raises one message for a bool, a string, a float, an
out-of-range integer and a zero alike, so a bool column was filed as a
1-based-contract violation. The taxonomy is therefore described by its two
axes now, not by its seven names.

The preferred queue loses its head entry and gains the reason it was there.
"Defensive limits first" reads like sequencing preference in hindsight; it was
not. The limits changed what the reference ACCEPTS, so they had to land
Python-first and cp1 had to be re-measured against them rather than merged
beside them.

Refs #250, #259.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CJF7MBi1ijU5m9cJVWgQsM